As wireless communications devices and methods have evolved it has become possible to employ the wireless telecommunications device, such as a cellular telephone or mobile station, in order to conduct e-commerce.
For example, in one evolving standard known as “Bluetooth”, the specification for which can be found at (http://www.bluetooth.com), a user is enabled to electronically pay for parking meters, bus tickets, shopping, movies and the like through the use of a short range (e.g., about 10 meters) wireless link (at 2.45 GHz) between the user's mobile station and a suitably equipped point of sale (POS) terminal, vending machine, etc. Data transmission speeds of between about 720 kbps and about 1000 kbps are expected to be feasible. In accordance with the Bluetooth standard each device is assigned a unique 12 byte address. In order to connect to the device the 12 byte address must be known.
The Wireless Applications Protocol (WAP) is another evolutionary step in the wireless telecommunications device area. The WAP specification can be found at (http://www.WAPforum.org. Basically, WAP takes a client server approach and incorporates a relatively simple “microbrowser” into the mobile station. The microbrowser is intended to require only limited resources of the mobile station, as the system intelligence is instead placed in external WAP gateways, thereby reducing the processing burden on the mobile station. WAP provides a user authentication service.
A WAP Identity Module (WIM) is an application stored in a tamper resistant device, such as a smartcard or a security Application Specific Integrated Circuit (ASIC), that provides public key infrastructure (PKI) based client authentication and digital signature services. The client authentication and digital signature services are based on private keys and digital certificates that are under the control of the WIM application. The WIM can be embedded within a SIM card or module, or ir could be plugged into the mobile station separately.
In a presentation entitled “WAP Terminal as an E-commerce device”, IBC Mobile Commerce-99 Conference “Internet Bank Security”, Juhani Miettunen proposed a WAP-enabled mobile station for use in mobile banking and other services. The mobile station is proposed for use in funds transfers between a user's accounts, for portfolio management, for bill payment and presenting, and for debit payments, credit payments, electronic purse and micropayments. The mobile station could include a “bank chip”, or a credit card chip, or some other type of plug-in or embedded device that enables the mobile station to be used for trusted financial and other applications, with secure user authentication.
It is known in the art to provide a Secure Electronic Transaction (SET) system for ensuring the security of financial transactions on the Internet. With SET, a user is given an “electronic wallet” (digital certificate), and a transaction is conducted and verified using a combination of digital certificates and digital signatures among the purchaser, a merchant, and the purchaser's bank. SET can make use of the Secure Sockets Layer (SSL), Secure Transaction Technology (STT), and Secure Hypertext Transfer Protocol (S-HTTP). SET uses some, but not all, of the public key infrastructure (PKI).
In the SET system a customer opens a bank account, typically through a credit card issuer, and receives a digital certificate. The digital certificate is an electronic file that functions as a credit card for online purchases and other transactions. It includes a public key with an expiration date, and is digitally signed by the bank to ensure its validity. Third party merchants also receive certificates from the bank. These certificates include the merchant's public encryption key and the bank's public encryption key. When the customer places an order over the Internet the customer's browser receives and confirms from the merchant's certificate that the merchant is valid. The browser then sends a message to the merchant with the order information. This message is encrypted with the merchant's public key, with payment information, which is encrypted with the bank's public key (and can't be read by the merchant), and information that ensures that the payment can only be used with this particular order. The merchant then verifies the customer by checking the digital signature on the customer's certificate. This may be done by referring the customer's certificate to the bank or to a third party verifier. The merchant then sends the order message along to the bank. This includes the bank's public key, the customer's payment information (which the merchant is incapable of decoding), and the merchant's certificate. The bank then verifies the merchant and the message using the digital signature on the certificate with the message. The bank also verifies the payment part of the message, then digitally signs and sends the authorization to the merchant, who can then fill the order.